Method and system for multiple symmetric decryption of .ZIP files

ABSTRACT

The present invention provides a method of integrating existing strong encryption methods into the processing of a .ZIP file to provide a highly secure data container which provides flexibility in the use of symmetric and asymmetric encryption technology. The present invention adapts the well established .ZIP file format to support higher levels of security and multiple methods of data encryption and key management, thereby producing a highly secure and flexible digital container for electronically storing and transferring confidential data.

BACKGROUND OF THE INVENTION

The present invention relates generally to a method of using standard.ZIP files and strong encryption technology to securely store files, andmore particularly to a method of integrating existing strong encryptionmethods into the processing of .ZIP files to provide a highly securedata container which provides flexibility in the use of symmetric andasymmetric encryption technology. The present invention adapts the wellestablished and widely used .ZIP file format to support higher levels ofsecurity and multiple methods of data encryption and key management,thereby producing an efficient, highly secure and flexible digitalcontainer for electronically storing and transferring confidential data.

Compression of computer files has been available for many years.Compressing files can save large amounts of disk space, and can reducetransfer time when downloading files from the Internet or transferringfiles through email. Almost any file one downloads from the Internet iscompressed in some way. A standard compressed file or folder as it issometimes called contains one or more files that were compressed into asingle file or folder. Many different compression formats have beendeveloped over the years. The .ZIP format, created by the assignee ofthe present invention, is perhaps the most common compressed file formatfor the personal computer. Any file with a “.zip” extension most likelycontains one or more files of data archived, that is, each eithercompressed or stored, in the .ZIP format. “Zipping” a file has become acommonly used term meaning to compress the file into the .ZIP formatarchive so that it occupies less disk space, and similarly, “unzipping”a file means decompressing a compressed file in the .ZIP format.

A .ZIP file is generally recognized as a data compression and archivingformat invented by PKWARE, Inc. The .ZIP format is a file formatdesigned for combining data compression technology with file archivingtechniques. Many commercially available software products are availablefor compressing or “zipping” files or other data into the .ZIP format.These .ZIP files can then be used to reconstruct the original datathrough the “unzipping” process. Data compression converts the contentsof a file into an encoded format requiring less computer storage spaceor in the case of transmission less network bandwidth than the originaluncompressed file.

Archiving, in the context of a .ZIP file, is a method of storinginformation about the characteristics of a file in a catalogue of files,known as the Central Directory, inside the .ZIP file, allowing each fileto be retrieved individually by its characteristics. This capability iswidely used. These characteristics include, but are not limited to, filename, file size, and file creation date and time.

Software programs such as PKZIP® written by PKWARE, Inc. are used toprocess files in the .ZIP format. Such programs allow one or more filesof any type to be compressed and archived into a file of the .ZIP formattype for efficient file storage and transmission over computer andcommunication networks. This format and the software programs thatprocess .ZIP files have become ubiquitous.

Data encryption is used by many software programs to provide dataprivacy. Data encryption is a method of encoding data so that it cannotbe reproduced in its original form unless an associated key is provided.Decryption uses this key to convert the encrypted data back into itsoriginal state. The key is known only to the person encrypting the dataor by those other people with whom the person encrypting the datachooses to share the key. The key is used to “unlock” the data so thatit can again be used in its original form.

Keys are uniquely generated using data known to the person encrypting afile or other data associated with recipients and users of the file.This data can be a user-defined password or other random data. Severalmethods are commonly used for processing the keys used for dataencryption. Encryption using a key generated from a password is anexample of symmetric encryption. Encryption using a public/private keypair is an example of asymmetric encryption. An example of one methodfor processing encryption keys supported by this invention uses apublic/private key pair commonly associated with digital certificates asdefined by the document Internet X.509 Public Key InfrastructureCertificate and CRL Profile (RFC 2459). A digital certificate is aunique digital identifier associating a public and private key pair toan assigned individual, a group, or an organization. When used forencrypting data, the public key of an individual is used to process anencryption key which only the individual in possession of thecorresponding private key can use for decryption. A digital certificateis issued to an individual, a group, or an organization for a fixedperiod of time and can only be used during this time period. After thetime period has elapsed, the digital certificate will be considered tohave expired and must be reissued for a new time period.

The strength of a data encryption method is determined at least in partby its key size in bits. The larger the key size a data encryptionmethod uses, the more resistant it is to cryptanalysis. Cryptanalysis,or popularly “cracking”, is the unauthorized access to encrypted data.Strong encryption is a type of data encryption that uses key sizes of128 bits or more. A number of encryption encoding methods are knowntoday. Examples supported by the present invention include but are notlimited to Advanced Encryption Standard (AES), Data Encryption Standard(DES), 2DES, 3DES, and others. A number of key sizes are commonly usedtoday. Examples supported by the present invention include but are notlimited to 128 bits, 192 bits, and 256 bits.

Many software programs available today that process .ZIP files use dataencryption to encrypt files after compression as they are written to the.ZIP file. The data encryption method used by these software programsuses a key size of 96 bits or less and is considered weak or moderateencryption by today's standards. These software programs use keysgenerated using user-defined password data. Weak data encryption may notprovide sufficient security to computer users that store and transfertheir confidential data files using the .ZIP format.

Password-based key generation has been a commonly used method ofapplying data encryption, however, known vulnerabilities to crackingmethods such as “brute force password cracking” make this method ofencryption insufficient to meet today's more advanced security needs.Another known limitation of password-based security is the lack ofnon-repudiation. Non-repudiation is the ability to be certain that theperson or program that created an encrypted .ZIP file cannot deny thatfact and that their identity is bound to the .ZIP file they created.This cannot be achieved with symmetric encryption methods. Today,non-repudiation is an important aspect of security related to theimplementation of digital certificates and digital signatures. It iscritically important to be able to prove that a creator or sender of anencrypted file did in fact create the file, i.e. not repudiate his/heraction.

Therefore, a need exists to extend the options for levels of securityavailable to programs that process .ZIP files. This extended of securitycapability makes use of the encryption technologies available today orothers that may gain acceptance in the future.

SUMMARY OF THE INVENTION

The present invention provides a method of integrating multiple strongencryption methods into the processing of .ZIP files to provide a highlysecure data container which provides flexibility in the use of symmetricand asymmetric encryption technology. The present invention adapts thewell established .ZIP file format to support higher levels of securityand multiple methods of data encryption and key management, therebyproducing a highly secure and flexible digital container for storing andtransferring confidential electronic data.

The present invention provides a method of integrating multiple strongencryption methods into the processing of .ZIP files to provide a highlysecure data container which provides flexibility in the use ofencryption technology. The present invention supports existing weakencryption methods available in .ZIP software programs used today toensure backward compatibility with existing software programs that usethe .ZIP file format. Strong encryption methods are made available tocomputer users as configurable options to select when compressing andencrypting their files or other data into a .ZIP file.

The method of the present invention provides the capability of usingstrong encryption when creating .ZIP files. It is flexible in that itprovides that different encryption methods can be applied to a single.ZIP file to meet the security needs of a given computer user orapplication. Strong encryption algorithms are preferably used inconjunction with either password (symmetric) or any form ofpublic/private key (asymmetric) encryption methods. The symmetric methodpreferably includes a password defined by the user, while the asymmetricmethod preferably includes a public/private key associated with digitalcertificates to process encryption keys. The invention allows one ormore passwords and one or more public keys to be used individually, orin combination at the same time when archiving any file of any type ofdata into a secure .ZIP file. This capability is useful since secure.ZIP files are frequently distributed, or otherwise made accessible, tomultiple recipients for decryption. Some of those recipients may requirepassword access while others may require certificate access.

The method of the present invention also supports the four basicsecurity functions to be associated with encrypted files:confidentiality, message authentication, sender or creatorauthentication, and non-repudiation.

Specifically, the present invention supports non-repudiation to uniquelybind a .ZIP file with the identity of its creator, and prevent thatcreator from denying the creation of that .ZIP file. One method ofnon-repudiation used by this invention is the identity support availablewith digital signatures that can be generated using public/private keytechnology. The non-repudiation function provided by the presentinvention also preferably supports time-stamping methods for fixing thecreation of a digital signature in time, as well as time-stamped audittrails providing transaction history.

As indicated, the method of the present invention also supports messageauthentication. Message authentication ensures the data has not beenaltered since being encrypted. The present invention supports messageauthentication techniques that employ public/private key forms ofmessage authentication, as well as other methods of messageauthentication that do not require the use of public/private keys. Oneexample of an alternative method that does not use a public/private keyis a cryptographic checksum.

The method of the present invention further supports the encryption offile characteristics for each file inside a .ZIP file. Current .ZIPsoftware programs encrypt only the contents of the files in a .ZIP file.The additional characteristics for each file, such as its name, size,etc., remain unencrypted. To remove the possibility that thisunencrypted data for a file could be made available to an unauthorizeduser, this information may preferably also be encrypted as an option.This additional encryption further increases the level of securityavailable to .ZIP file users.

Public keys such as those associated with digital certificates used forencrypting .ZIP file data preferably resides on a user's local computerin a file or a database, on an external device such as a Smart Card orother removable device, or in a shared data repository such as adirectory service served by an LDAP server.

The present invention also provides multiple methods of checking whethera digital certificate is valid for use. These methods preferablyinclude, but are not limited to standard methods of certificatevalidation, such as searching certificate revocation lists (CRL),certificate trust lists (CTL), and online checking via the internetusing Online Certificate Status Protocol (OCSP) or Simple CertificateValidation Protocol (SCVP).

The method of the present invention also preferably defines data storagelocations within the established .ZIP file format specification forstoring information on the encryption parameters used when a file wasencrypted and on the keys needed when a file is to be decrypted. Onesuch example of these data storage locations includes a field toidentify that a new strong encryption method has been applied to a filein the .ZIP file. The strong encryption record will be defined within aCentral Directory storage area for each encrypted file. The CentralDirectory is a storage location defined in the .ZIP file format whichserves as a table of contents for the entire .ZIP file. An entry is madeinto the Central Directory for each file added to a .ZIP file. Adecryption record will be defined for storing the information needed toinitialize and start the decryption process. This decryption record willbe placed immediately ahead of the encrypted data for each file in a.ZIP file. This example is not the only method of storing this data asother storage methods can be defined.

The present invention provides many advantages or benefits over theprior art. One benefit is the ability to use multiple encryption methodsinstead of supporting only a single encryption method. A second benefitis the ability to use a mixture of symmetric and asymmetric encryptionin a single, secure .ZIP file. A third benefit is that the encryption ofindividual files using advanced public/private keys provides asignificantly higher level of security to computer users. A fourthbenefit is that encryption of .ZIP file data can be implemented using arange of commonly available cryptographic toolkits. A fifth benefit isthat the present invention supports using packaged or readily availableencryption algorithms to provide state-of-the-art security. A sixthbenefit is the availability of non-repudiation using digital signaturesthrough the use of public/private key technology. A seventh benefit isthat the invention ensures a high degree of interoperability andbackward compatibility by extending the current .ZIP file format.

Various other features, objects, and advantages of the invention will bemade apparent to those skilled in the art from the following detaileddescription, claims, and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a record layout of a prior art .ZIP file prior to the presentinvention.

FIG. 2 is a record layout of a .ZIP file in accordance with the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

Referring now to the drawings, FIG. 1 shows the file format for thestandard .ZIP file, in existence prior to the present invention. FIG. 2illustrates the preferred general record layout of a .ZIP file inaccordance with the present invention.

The newly modified .ZIP file format specification according to thepresent invention, as published by PKWARE, Inc., is described in adocument entitled APPNOTE.TXT, which is attached hereto and incorporatedherein by reference. The new version of the .ZIP file format provides animplementation of the use of strong encryption based on a key generatedusing a password. This implementation constitutes one example of astructure and layout of the records and fields suitable for processingsecure .ZIP files as defined by the present invention. The completedescription of the conventional or standard .ZIP file format will not beincluded here since this information is generally well known. Only theportions pertaining to the new records and fields defined by the newformat, capable of storing data using strong encryption, will bediscussed in detail.

The present invention extends the original .ZIP file format with theaddition of new storage records to support the use of strong encryptionmethods including, as described above, both public/private key, orasymmetric, methods, and password-based, or symmetric, methods, and thecapability to use a mixture of symmetric and asymmetric methods.

An example of implementing a new strong encryption method is discussedbelow. This example identifies several new records and fields that mustbe defined within the .ZIP file format.

A new General Purpose Bit Flag having a hexadecimal value of 0x0040 tobe set in both the Local and Central Record Headers when stronglyencrypting a file.

A new Decryption Header to be located immediately ahead of and adjacentto the compressed data stored for each file.

A new Extra Field record definition with an ID having a hexadecimalvalue of 0x0017 to be inserted into the Central Record Header for eachfile.

When using these new fields for strongly encrypting files, the followingactions are indicated.

1. If the General Purpose Bit Flag value of 0x0040 is set to indicatestrong encryption was applied to a file, the General Purpose Bit Flagvalue of 0x0001 will also generally be set.

2. Files having a size of zero bytes (an empty file) should notgenerally be encrypted. As indicated, however, the file characteristicsof the archived files may be encrypted, even if the file is of zerolength and is not itself encrypted.

3. The contents of the field labeled Version Needed to Extract in boththe Local and Central Record Headers should preferably be set to thedecimal value of 50 or greater. If the AES encryption method is used,the contents of the field labeled Version Needed to Extract in both theLocal and Central Record Headers should preferably be set to the decimalvalue 51 or greater.

4. Data encryption should preferably be applied after a file iscompressed, but encryption can be applied to a file if compression isnot used. If compression is not applied to a file, it is considered tobe stored in the .ZIP file.

5. If encryption is applied using digital certificates, a list ofintended recipients will be constructed. Each entry in the recipientlist identifies a person whose public key has been used in theencryption process for a file and who is allowed to decrypt the filecontents using their private key.

Record Definitions: New Decryption Header (NDH) Size Value (bytes)Description IV size 2 Size of custom initialization vector/salt, if 0then CRC32 + 64-bit File Size should be used to decrypt data. IVvariable Initialization vector/salt (file specific) which should be usedin place of CRC32 + 64-bit File Size Original Size 4 Original(uncompressed) size of the following data Decryption Info. variableDecryption Information

Decryption Information (details) Size Value (bytes) Description Version(3) 2 Version/Format of decryption information. AlgID 2 EncryptionAlgorithm ID BitLen 2 Bit length of the key Flags 2 Processing flags ERDsize 2 Size of Encrypted Random Data (ERD) ERD variable Encrypted RandomData Recipient Count 4 Number of Recipients Hash Algorithm 2 Hashalgorithm to be used to calculate Public Key hash (absent for passwordbased encryption) Hash Size 2 Size of Public Key hash (absent forpassword based encryption) Recipient List variable Recipient ListElement (absent for password Element based encryption) Password 2 Sizeof random password validation data Validation Data (Includes CRC32 ofPVD; >4) MUST size be multiple of encryption block sizes Password,variable Password Validation Data (PVD) Validation Data CRC32 of PVD 4CRC32 of PVD, used for password verification when decrypting data

Encryption Algorithm ID (AlgID) identifies which of several possiblestrong encryption algorithms was used for encrypting a file in the .ZIPfile. The strong encryption algorithms that can be used include but arenot limited to AES, 3DES, 2DES, DES, RC2 and RC4. The use of otherunspecified strong algorithms for encryption is supported by the presentinvention.

Hash Algorithm identifies which of several possible hash algorithms wasused for the encryption process for a file in the .ZIP file. Thealgorithms that can be used include but are not limited to MD5,SHA1-SHA512. The use of other unspecified algorithms for hashing issupported by the present invention.

Flags

The following values are defined for the processing Flags. Name ValueDescription PASSWORD_KEY 0x0001 Password is used CERTIFICATE_KEY 0x0002Recipient List is used COMBO_KEY 0x0003 Either a password or a RecipientList can be used to decrypt a file DOUBLE_SEED_KEY 0x0007 Both passwordand Recipient List are required to decrypt a file. ERD is encryptedtwice by 2 separate keys. DOUBLE_DATA_KEY 0x000f Both a password and aRecipient List are required to decrypt a file. File data is encryptedtwice using 2 separate keys. MASTER_KEY_3DES 0x4000 Specifies 3DESalgorithm is used for MSK

Recipient List Element Size Value (bytes) Description Recipient 2Combined size of Hash of Public Element size Key and Simple Key BlobHash Hash Size Hash of Public Key Simple key Blob variable Simple KeyBlob

New Decryption Central Record Extra Field (NDCEF) Size Value (bytes)Description 0x0017 2 Signature of NDCEF Data Size 2 Size of thefollowing data (at least 12 bytes) Version (2) 2 Version/Format of thisextra field. AlgID 2 Encryption Algorithm ID. BitLen 2 Bit length of thekey Flags 2 Processing flags Recipient Count 4 Number of Recipients HashAlgorithm 2 Hash algorithm to be used to calculate Public Key hash(absent for password based encryption) Hash Size 2 Size of Public Keyhash (absent for password based encryption) Simplified variableSimplified Recipient List Element Recipient List (absent for passwordbased encryption) Element

Simplified Recipient List Element Size Value (bytes) Description HashHash Hash of Public Key Size

A simplified recipient list element is defined as a subset of arecipient list element and is stored to provide redundancy of therecipient list data for the purposes of data recovery.

Process Flow:

The following is a description of the most preferredencryption/decryption process for a single file using the storage formatdefined by this example. Any programs, software or other processesavailable to suitably perform the encryption/decryption process may beused.

Encryption:

-   1. Validate public/private key-   2. Calculate file digital signature and time-stamp-   3. Compress or Store uncompressed file data-   4. Generate a File Session Key (FSK) (see below)-   5. Calculate Decryption Information size-   6. Adjust Compressed Size to accommodate Decryption Information and    padding-   7. Save Decryption Information to .ZIP file-   8. Encrypt Compressed or Stored File Data-   9. Encrypt file characteristics    Decryption:-   1. Decrypt file characteristics-   2. Read Decryption Information from .ZIP file-   3. Generate FSK (see below)-   4. Verify Decryption Information (see below)-   5. If Decryption Information is valid, then decrypt Compressed or    Stored File Data-   6. Decompress compressed data-   7. Validate file time-stamp and digital signature    Generating Master Session Key (MSK)-   1. If MASTER_KEY_(—)3DES is set, use 3DES 3-key as MSK algorithm,    otherwise use specified algorithm.-   2. If encrypting or decrypting with a password.-   2.1.1. Prompt user for password-   2.1.2. Calculate hash of the password-   2.1.3. Pass calculated hash as argument into a cryptographic key    derivation function or its equivalent.-   3. When encrypting using a public key (MSK)-   3.1.1. Call a cryptographic key generation function or its    equivalent to generate random key-   4. When decrypting using a private key(s).    -   4.1 Using Recipient List information, locate private key, which        corresponds to one of the public keys used to encrypt MSK    -   4.2 Decrypt MSK        Salt and/or Initialization Vector (IV)-   1. For algorithms that use both Salt and IV, Salt=IV-   2. IV can be completely random data and placed in front of    Decryption Information-   3. Otherwise IV=CRC32+64-bit File Size    Adjusting Keys-   1. Determine Salt and/or Initialization Vector size of the key for    the encryption algorithm specified. Usually salt is compliment to    128 bits, so for 40-bit key Salt size will be 11 bytes.    Initialization Vector is usually used by block algorithms and its    size corresponds to the block size.-   2. If Salt size >0 or Initialization Vector size is >0 then set IV¹    to be used by the specified encryption algorithm.    ¹When adjusting MSK, if IV is smaller then required Initialization    Vector (or Salt) size it is complimented with 0, if it is larger it    is truncated. For all other operations TV is used as is without any    modifications.    Generating File Session Key (FSK)-   1. FSK<-SHA1(MSK(IV)). Adjust MSK with IV, and decrypt ERD    (Encrypted Random Data). Calculate hash of IV+Random Data. Pass    calculated hash as argument into a cryptographic key derivation    function or its equivalent to obtain FSK    Verifying Decryption Information-   1. Decryption Information contains variable length Password    Validation Data (PVD).-   2. First Password Validation Data Size—4 bytes are random data, and    last 4 bytes are CRC32 of that random data. This allows verification    that the correct key is used and deters plain text attacks.

The following modifications are used for encrypting and decryptingmultiple files.

Multi-File Encryption:

-   1. Generate MSK-   2. For each file follow Encryption steps.    Multi-File Decryption:-   1. Generate MSK from the file Decryption Information-   2. For each file follow Decryption steps-   3. If Decryption Information verification fails go to step 1

Alternate storage formats can be defined for implementing the flexiblesecurity support within .ZIP files. One such alternative is to use otherfields, either existing or newly defined to denote that a strongencryption method was applied to a .ZIP archive. Another alternativecould be to use additional storage fields in addition to those definedin the above example, or to use the fields as defined, but ordereddifferently within each record. Still other implementations may usefewer, or more, records or fields than are defined by the above exampleor the records and fields may be placed in other physical locationswithin the .ZIP file.

Alternate processing methods can also be defined for implementing theflexible security support within .ZIP files. One such alternative is toimplement the encryption process for each file using anotherpublic/private key technology such as that defined by the OpenPGPMessage Format as documented in RFC 2440. Another alternative could beto use a more direct form of encryption key generation where the filesession key is directly used for encrypting each file. This method wouldnot use the indirect form described in the above example where the filesession key is derived from a master key.

While the invention has been described with reference to preferredembodiments, it is to be understood that the invention is not intendedto be limited to the specific embodiments set forth above. Thus, it isrecognized that those skilled in the art will appreciate that certainsubstitutions, alterations, modifications, and omissions may be madewithout departing from the spirit or intent of the invention.Accordingly, the foregoing description is meant to be exemplary only,the invention is to be taken as including all reasonable equivalents tothe subject matter of the invention, and should not limit the scope ofthe invention set forth in the following claims.

1. A method of providing access to data in a .Zip file format datacontainer, said method including: receiving a data container constructedin accordance with a .Zip file format, said data container including:first symmetric key data; second symmetric key data; and an encrypteddata file, wherein said first symmetric key data was derived bysymmetrically encrypting, using a first symmetric key, an intermediatesymmetric key that was used to encrypt said encrypted data file, whereinsaid second symmetric key data was derived by symmetrically encrypting,using a second symmetric key, said intermediate symmetric key that wasused to encrypt said encrypted data file receiving a decryption keyinput; providing the option of: using said first symmetric key data incombination with said decryption key input to recover said intermediatesymmetric key to symmetrically decrypt said encrypted data file to forma decrypted data file when said decryption key is a desired firstsymmetric key; and using said second symmetric key data in combinationwith said decryption key input to recover said intermediate symmetrickey to symmetrically decrypt said encrypted data file to form adecrypted data file when said decryption key is a desired secondsymmetric key; and providing access to said decrypted data file.
 2. Themethod of claim 1 further including decompressing said decrypted datafile.
 3. The method of claim 2 wherein said decompressing employs aLempel-Ziv (LZ)-type data decompression algorithm.
 4. The method ofclaim 2 wherein said decompressing employs a Deflate-type datadecompression algorithm.
 5. The method of claim 2 wherein saiddecompressing employs a Burrows-Wheeler Transform (BWT)-type datadecompression algorithm.
 6. The method of claim 1 wherein said decrypteddata file is not decompressed.
 7. The method of claim 1 wherein at leastpart of one of said first symmetric key, said second symmetric key, andsaid intermediate symmetric key is composed of random data.
 8. Themethod of claim 7 wherein at least part of said first symmetric key iscomposed of a first set of random data and at least part of said secondsymmetric key is composed of a second set of random data.
 9. The methodof claim 8 wherein said first set of random data is not equal to saidsecond set of random data.
 10. The method of claim 1 wherein at leastpart of said decryption key is received from a user.
 11. The method ofclaim 10 wherein at least part of said decryption key is a password. 12.The method of claim 1 wherein said desired first symmetric key input isdifferent from said desired second symmetric key input.
 13. The methodof claim 1 wherein at least one of said first symmetric key, said secondsymmetric key, and said intermediate symmetric key has a key length ofat least 128 bits.
 14. The method of claim 1 wherein at least one ofsaid first symmetric key, said second symmetric key, and saidintermediate symmetric key has a key length of at least 192 bits. 15.The method of claim 1 wherein at least one of said first symmetric key,said second symmetric key, and said intermediate symmetric key has a keylength of at least 256 bits.
 16. The method of claim 1 wherein saidsymmetrically decrypting said encrypted data file uses an AES decryptiondecoding operation.
 17. The method of claim 1 wherein said symmetricallydecrypting said encrypted data file uses a 3DES decryption decodingoperation.
 18. A method of providing access to data in a .Zip fileformat data container, said method including: receiving a data containerconstructed in accordance with a Zip file format, said data containerincluding: first symmetric key data; second symmetric key data; and anencrypted data file, wherein said first symmetric key data was derivedfrom a first symmetric key that was used to symmetrically encrypt saidencrypted data file, wherein said second symmetric key data was derivedfrom a second symmetric key that was used to symmetrically encrypt saidencrypted data file, receiving a decryption key input; providing theoption of: using said first symmetric key data in combination with saiddecryption key input to recover said first symmetric key tosymmetrically decrypt said encrypted data file to form a decrypted datafile when said decryption key is a desired first symmetric key; andusing said second symmetric key data in combination with said decryptionkey input to recover said second symmetric key to symmetrically decryptsaid encrypted data file to form a decrypted data file when saiddecryption key is a desired second symmetric key; and providing accessto said decrypted data file.
 19. The method of claim 18 furtherincluding decompressing said decrypted data file.
 20. The method ofclaim 19 wherein said decompressing employs a Lempel-Ziv (LZ)-type datadecompression algorithm.
 21. The method of claim 19 wherein saiddecompressing employs a Deflate-type data decompression algorithm. 22.The method of claim 19 wherein said decompressing employs aBurrows-Wheeler Transform (BWT)-type data decompression algorithm. 23.The method of claim 18 wherein said decrypted data file is notdecompressed.
 24. The method of claim 18 wherein at least part of one ofsaid first symmetric key and said second symmetric key is composed ofrandom data.
 25. The method of claim 24 wherein at least part of saidfirst symmetric key is composed of a first set of random data and atleast part of said second symmetric key is composed of a second set ofrandom data.
 26. The method of claim 25 wherein said first set of randomdata is not equal to said second set of random data.
 27. The method ofclaim 18 wherein at least part of said decryption key is received from auser.
 28. The method of claim 27 wherein at least part of saiddecryption key is a password.
 29. The method of claim 18 wherein saiddesired first symmetric key input is different from said desired secondsymmetric key input.
 30. The method of claim 18 wherein at least one ofsaid first symmetric key and said second symmetric key has a key lengthof at least 128 bits.
 31. The method of claim 18 wherein at least one ofsaid first symmetric key and said second symmetric key has a key lengthof at least 192 bits.
 32. The method of claim 18 wherein at least one ofsaid first symmetric key and said second symmetric key has a key lengthof at least 256 bits.
 33. The method of claim 18 wherein saidsymmetrically decrypting said encrypted data file uses an AES decryptiondecoding operation.
 34. The method of claim 18 wherein saidsymmetrically decrypting said encrypted data file uses a 3DES decryptiondecoding operation.
 35. A method of providing access to data in a datacontainer, said method including: receiving a data container designedfor containing compressed files, said data container including: firstsymmetric key data; second symmetric key data; and an encrypted datafile, wherein said first symmetric key data was derived by symmetricallyencrypting, using a first symmetric key, an intermediate symmetric keythat was used to encrypt said encrypted data file wherein said secondsymmetric key data was derived by symmetrically encrypting, using asecond symmetric key, said intermediate symmetric key that was used toencrypt said encrypted data file receiving a decryption key input;providing the option of: using said first symmetric key data incombination with said decryption key input to recover said intermediatesymmetric key to symmetrically decrypt said encrypted data file to forma decrypted data file when said decryption key is a desired firstsymmetric key; and using said second symmetric key data in combinationwith said decryption key input to recover said intermediate symmetrickey to symmetrically decrypt said encrypted data file to form adecrypted data file when said decryption key is a desired secondsymmetric key; and providing access to said decrypted data file.
 36. Themethod of claim 35 further including decompressing said decrypted datafile.
 37. The method of claim 36 wherein said decompressing employs aLempel-Ziv (LZ)-type data decompression algorithm.
 38. The method ofclaim 36 wherein said decompressing employs a Deflate-type datadecompression algorithm.
 39. The method of claim 36 wherein saiddecompressing employs a Burrows-Wheeler Transform (BWT)-type datadecompression algorithm.
 40. The method of claim 35 wherein saiddecrypted data file is not decompressed.
 41. The method of claim 35wherein at least part of one of said first symmetric key, said secondsymmetric key, and said intermediate symmetric key is composed of randomdata.
 42. The method of claim 41 wherein at least part of said firstsymmetric key is composed of a first set of random data and at leastpart of said second symmetric key is composed of a second set of randomdata.
 43. The method of claim 42 wherein said first set of random datais not equal to said second set of random data.
 44. The method of claim35 wherein at least part of said decryption key is received from a user.45. The method of claim 44 wherein at least part of said decryption keyis a password.
 46. The method of claim 35 wherein said desired firstsymmetric key input is different from said desired second symmetric keyinput.
 47. The method of claim 35 wherein at least one of said firstsymmetric key, said second symmetric key, and said intermediatesymmetric key has a key length of at least 128 bits.
 48. The method ofclaim 35 wherein at least one of said first symmetric key, said secondsymmetric key, and said intermediate symmetric key has a key length ofat least 192 bits.
 49. The method of claim 35 wherein at least one ofsaid first symmetric key, said second symmetric key, and saidintermediate symmetric key has a key length of at least 256 bits. 50.The method of claim 35 wherein said symmetrically decrypting saidencrypted data file uses an AES decryption decoding operation.
 51. Themethod of claim 35 wherein said symmetrically decrypting said encrypteddata file uses a 3DES decryption decoding operation.
 52. The method ofclaim 35 wherein said data container is constructed in accordance with a.Zip file format.
 53. A method of providing access to data in a datacontainer, said method including: receiving a data container designedfor containing compressed files, said data container including: firstsymmetric key data; second symmetric key data; and an encrypted datafile, wherein said first symmetric key data was derived from a firstsymmetric key that was used to symmetrically encrypt said encrypted datafile, wherein said second symmetric key data was derived from a secondsymmetric key that was used to symmetrically encrypt said encrypted datafile, receiving a decryption key input; providing the option of: usingsaid first symmetric key data in combination with said decryption keyinput to recover said first symmetric key to symmetrically decrypt saidencrypted data file to form a decrypted data file when said decryptionkey is a desired first symmetric key; and using said second symmetrickey data in combination with said decryption key input to recover saidsecond symmetric key to symmetrically decrypt said encrypted data fileto form a decrypted data file when said decryption key is a desiredsecond symmetric key; and providing access to said decrypted data file.54. The method of claim 53 further including decompressing saiddecrypted data file.
 55. The method of claim 54 wherein saiddecompressing employs a Lempel-Ziv (LZ)-type data decompressionalgorithm.
 56. The method of claim 54 wherein said decompressing employsa Deflate-type data decompression algorithm.
 57. The method of claim 54wherein said decompressing employs a Burrows-Wheeler Transform(BWT)-type data decompression algorithm.
 58. The method of claim 53wherein said decrypted data file is not decompressed.
 59. The method ofclaim 53 wherein at least part of one of said first symmetric key andsaid second symmetric key is composed of random data.
 60. The method ofclaim 59 wherein at least part of said first symmetric key is composedof a first set of random data and at least part of said second symmetrickey is composed of a second set of random data.
 61. The method of claim60 wherein said first set of random data is not equal to said second setof random data.
 62. The method of claim 53 wherein at least part of saiddecryption key is received from a user.
 63. The method of claim 62wherein at least part of said decryption key is a password.
 64. Themethod of claim 53 wherein said desired first symmetric key input isdifferent from said desired second symmetric key input.
 65. The methodof claim 53 wherein at least one of said first symmetric key and saidsecond symmetric key has a key length of at least 128 bits.
 66. Themethod of claim 53 wherein at least one of said first symmetric key andsaid second symmetric key has a key length of at least 192 bits.
 67. Themethod of claim 53 wherein at least one of said first symmetric key andsaid second symmetric key has a key length of at least 256 bits.
 68. Themethod of claim 53 wherein said symmetrically decrypting said encrypteddata file uses an AES decryption decoding operation.
 69. The method ofclaim 53 wherein said symmetrically decrypting said encrypted data fileuses a 3DES decryption decoding operation.
 70. The method of claim 53wherein said data container is constructed in accordance with a .Zipfile format.